I've crawled out from underneath my Mondo Rescue stone and looked in bewilderment at the various vote messages in my inbox. (It's not quite as bad, I've followed things to some detail passively on private and planet.)

The main questions seem to be:

• Is it good or bad to collect money to pay people for getting specific tasks done in Debian? Does involvement of the DPL in such an initiative constitute a conflict of interest?

• What is more important to the project, freedom of the content or hardware compatibility of the system shipped with Etch?

Here is how I've voted and why:

a65763d3-b1e2-4530-8ff8-aa5915274eb4
[ 1 ] Choice 1: Re-affirm DPL, wish success to unofficial Dunc Tank
[ 2 ] Choice 2: Re-affirm DPL, do not endorse nor support his other projects
[ ] Choice 3: Further discussion

49a98df6-2bd4-40c8-a559-7e15212dbd26
[ ] Choice 1: Recall the project leader
[ 1 ] Choice 2: Further discussion

I think AJ is trying to improve things in Debian and that Dunc Tank is one attempt to do so. I believe it is a worthwhile attempt and can understand that he wants to be involved. While I also understand the concerns raised by other people, I believe that only time will tell whether Dunc Tank is in fact good or bad for Debian (I hope it's good). As far as the conflict of interest issue goes, I think it's less than ideal but the smaller evil to keep AJ as DPL whilst he's involved with Dunc Tank. I don't think AJ should run again if he stays involved in Dunc Tank as he is at the moment. I think that we need to consider integrating Dunc Tank into Debian if it is still alive and kicking in 12 months time. (Or to set up something similar as part of the project.)

c2d43675-9efa-4809-a4aa-af042b62786e
[ 1 ] Choice 1: Release Etch even with kernel firmware issues
[ 2 ] Choice 2: Special exception to DFSG2 for firmware as long as required [3:1]
[ ] Choice 3: Further discussion

22fc4edd-1f6c-454f-b204-6aa0bad0ce1d
[ ] Choice 1: DFSG #2 applies to all programmatic works
[ 1 ] Choice 2: Further discussion

I believe that we should indeed release Etch as planned even if that means shipping a number of firmware blobs. I do not think that an ongoing exception is appropriate here. If this is still not resolved by the time we want to release Etch+1, let's have an other GR.

I am not sure what "program" really means in DFSG #2 - I've always taken it to mean the software, documentation, fonts and artwork that we ship as part of Debian. It likely has to comprise more than that, but I am convinced there have to be some exceptions:

• It defeats the purpose and very nature to modify licence texts. If people can change a licence at will, there is not much point having one in the first place.
  
• It equally defeats the purpose to modify logos (and thus their representations as files of whatever format). Logos allow users to recognise more easily what content is available. It does not make sense to allow modification or use in a different context of such a logo as it would then be more confusing than helpful.*
  

I believe that these are just two examples of potentially many where 'free' versus 'non-free' are inadequate categories to think in.

Finally, the DFSG are part of the Social Contract and not the other way round. I like this because I value doing the best for our users higher than some rules. The DFSG exist to empower our users - I don't believe that removing firmware blobs from the kernel serves this purpose. That said, we should by all means strive towards free firmware, but I view this as more of an incremental, ongoing task of convincing vendors over time.

* I believe for example that the dispute over Firefox would be best resolved by Debian using the Firefox logo (and name) and the Mozilla folks dropping there requirement for patch review.

Bug #385790 prompted me to set up an AFS client on my sid installation. This is something I hadn't done since I left uni almost nine years ago. Back then it was a bit fiddly to get the Transarc AFS client for Linux to work if I remember correctly.

Things have quite obviously improved since then. The following is all that was required (with some helpful information provided by the submitter - thanks, Kevin!):

• install packages openafs-modules-source and module-assistant
  
• follow the instructions in /usr/share/doc/openafs-modules-source/README.modules, i.e:
• module-assistant prepare openafs-modules
• module-assistant auto-build openafs-modules
• dpkg -i /usr/src/openafs-modules-.deb
  
• install package openafs-client and configure like this:
• leave AFS cell of workstation at default, i.e. local domain
  
• leave cache at 50000 kb
• leave DB server host for home cell blank
• answer 'Yes' to 'Run Openafs client now and at boot?'
• if this doesn't work, run dpkg-reconfigure openafs-client like this:
• leave AFS cell of workstation at default, i.e. local domain
• leave cache at 50000 kb
• answer 'Yes' to 'Run Openafs client now and at boot?'
• answer 'Yes' to 'Look up AFS cells in DNS?'
• answer 'Yes' to 'Encrypt authenticated traffic with AFS fileserver?'
• answer 'Yes' to 'Dynamically generate the contents of /afs?'
• answer 'Yes' to 'Use fakestat to avoid hangs when listing /afs?'
• leave DB server host for home cell blank
• answer 'Yes' to 'Run Openafs client now and at boot?' (again)
  
• ...and restart openafs-client afterwards

(The need to reconfigure may be a bug, not sure.)

In summary, OpenAFS and Sam Hartman's packaging effort make AFS a breeze to install on Debian!

Now all I have to do is find the time to fix the bug. ;-)

[Update] Important detail I forgot to mention: Open port 7001 on your firewall for UDP.
[Update] Added what to answer, i.e. 'Yes'. Doh.

I have some hopes that mindi 1.20 and mondo 2.20 will be released sufficiently early for the freeze (i.e. soon ;-) ). To help ensuring that things are indeed in good shape at release time, I thought, I make some pre-release packages available.

Please test and send feedback - good or bad!

I've done some testing myself on amd64/DVD and i386/NFS with good results apart from the missing fixes for #320152 and #379966 - they will be in upstream or the final package versions though.

Just noticed the new native 2.04~rc2 OpenOffice packages for amd64 in unstable. My first impression is: Wow, I've never seen writer starting up so fast! (Way under a second.)

Congratulations to the Debian OpenOffice.org Team!

...is what Mike Connor appears to be suggesting here. As far as I can tell, this has already happened - the way I interpret #8 of the DFSG, it is not just about Debian and derivatives but absolutely everyone including Osama Bin Laden and George Walker Bush and even John Howard. ;-)

Seriously, though, I perfectly understand that Mozilla needs to protect its brand and they certainly have every right to do so. And we have every right to change the name and modify the code without asking anyone for approval. A right that we will have to exercise by the looks of it. How about 'freefox' (probably too close) or the 'browser otherwise known as firefox', short 'bokaf' (anyone?).

I believe that Mozilla is doing the free software movement a disservice when they are as hard-nosed about their brand as it appears they are. They certainly need to put mechanisms in place to protect themselves from the Dr. Evils of the world. Debian most definitely does not belong into this category (neither do Redhat nor Suse nor any other Linux distribution I can think of). So why not just let sleeping dogs lie?

Eric Dorland and Steve Langasek are my heroes for remaining calm and on topic in the discussion.

I've finally uploaded mondo-2.09-3 packages which contain the changes to get Mondo Rescue working with AFS to fix #385790. I should have communicated better with Bruno because he has done some work in parallel on this. We have come largely to the same conclusions, though, which is always reassuring.

2.09-3 also has some more changes done in the post-nuke arena. I felt that because it is now an integral part of the Debian package it needed some more love. Changes are:

• Log the fact that no post-nuke script was found during restore.
• Perform after nuke steps even if we dropped back to interactive mode because of issue with mount list.
• Ask user after nuke to wait until s/he is returned to command prompt before rebooting.
• Use run_program_and_log_output() instead of system() to get output of post-nuke logged.
• Output screen messages about post-nuke.

With these changes added, post-nuke behaviour is still not perfect but probably good enough for now. Hopefully, Bruno agrees and accepts the changes upstream.

Finally, I've managed to get hold of a VXA-1a tape streamer. It's IDE which sucks because Debian removed ide-scsi from the standard kernels a while back, so the vxaTool doesn't work (yes, I know how to compile kernels, but I like to run a standard environment so that I can pick up on and reproduce issues). Then again, it's just for testing anyway and I can report that I've successfully done test runs with Mondo Rescue using it.

Speaking of testing, mondo-2.09-3 was tested:

• on sid amd64
• running kernel 2.6.17-2-amd64 (2.6.17-9)
• using DVD and tape (!!) as backup media (NFS is still stuffed)

(mindi-2.09-2 which I uploaded a few days ago was basically tested the same.)

SAP has supported Linux for many years. Debian, though, is not one of the supported distributions which I find unfortunate because I am an SAP consultant and a Debian developer. ;-)

I have manually installed an SAP Testdrive system on Debian from RPM packages years ago which was very painful. Gregor Wolf's instructions on SDN make things look much less daunting for a regular install. Hopefully, I'll have a chance to try this in the next couple of months...

Mark's take on what Debian's strengths and weaknesses are makes for an interesting read. The way I interpret it, he wants us to be the plateau that other parties can put their spikes on top of (to use his symbolism). He mentions etch towards the end as one of those spikes, but essentially suggests we focus pretty much all our energy on sid because this is what we are good at and where our passion lies.

I beg to differ.

I firmly believe that Debian must remain relevant as an end-user distribution. Not only because essentially this is what our Social Contract is all about but also because without (relevant) releases I very much doubt we'd be able to keep the momentum and attract (or even keep) good people as (new) developers.

From Mark's point of view, his line of argumentation certainly makes sense: The better sid, the better a derivative like Ubuntu. From our point of view I believe it doesn't.

And by the way, I do run sarge on my machine as "production" environment and I am thus much looking forward to the release of etch.

That said, I do think that Ubuntu is better than Debian in some ways (but certainly not all), so on this I agree with Mark. I am just not sure that this really has to stay this way. Competition is good. ;-)

Nothing like the above to get a bit of an audience, I guess... ;-)

I tried the freely available (i.e. no Passport account or other crap required) pre-RC1 build of Windows Vista sometime last week. Whilst I didn't delve all that deeply into new stuff that's under the bonnet, I played around with the new Aero GUI a bit. And I must say that I'm somewhat impressed. I thought the Luna style of XP was totally, utterly and completely ridiculous when I first saw it. Compared to that, Aero is quite neat and subtle. I rather like the frosted glass effect of the window title bar, the way windows are stacked at an angle for easy selection, the glowing window buttons and a few other bits and pieces.

I've since wiped that disk and installed Fedora Core 6 Test 2 to have a look at AIGLX/Compiz. I thought I use Fedora since this is where AIGLX originates. I'm not at all excited about XGL because it appears to pretty much require proprietary drivers - not good. (I've actually got a Radeon 9600 which has experimental but AFAICS working 3D acceleration in Xorg from version 7.0). So far, so good. I got the cube thing working, wobbly windows, window and menu shadows, minimise/restore window effects, the 'film' desktop chooser, transparency on move and likely more that I can't recall right now. It's all working and not crashing. The only issue is that it doesn't feel "natural" (for lack of a better word). Maybe it's because there is a bit of a lag when doing something for the first time or after a while, i.e. moving a new and large window or spinning the desktop cube. I certainly think that my Radeon 9600 card should be up to it - after all it spins the cube at break-neck speeds. When doing similar things on OSX or even Vista it feels like this is just what you do; with AIGLX/Compiz it more feels like "Look what I can do!" without that certain matter-of-course-ness. Or, to reveal my age ;-), it feels a bit like early eighties pop music that had just discovered the possibilities of digital synthesizers. (Also, and this can probably be considered a real bug, scrolling in Firefox is dead slow with AIGLX/Compiz.)

Having said all that, I'm surely and truly excited about the possibilities of a vectorised desktop and think it's got oodles of potential. And I'm equally surely and truly appreciating the work people have put into this. I've merely come to realise that the blurred videos on youtube may not necessarily convey the current state of affairs with total accuracy.

For some reason, I always thought that it costs money to access the POSIX Standard. Not so - it's freely available (and they even provide a Firefox search plugin)!

I've just uploaded mondo 2.09-2 which comes with a number of improvements and bug fixes (one reported and more unreported):

• No more garbled screens or error messages because of insufficiently escaped strings used in system() or popen(). (Well, not quite true, but the one known issue should be fixed now with new function module mr_stresc() that can be used wherever else needed.)
• mondorestore will now ask in non-nuke mode whether an existing post-nuke script is to be executed. (Doing this is generally a good idea on Debian as the post-nuke script in the package updates the initrd image to adjust for RAID and other system changes.)
  
• Fixed issue where stabgrub-me would fail if /etc/grub.conf is a symbolic link preventing the user from editing the grub config file. (This requires readlink which I've added to mindi-busybox, hence the new mindi-busybox package version.)
• I was getting segmentation faults in space_occupied_by_cd() - it's not a good idea to do fin = popen(...) followed by fgets(...,...,fin) without checking the success of the former. Fixed this by evaluating errno after the popen() call. (Strangely, with the errno checking in place, popen() doesn't seem to fail anymore, which might indicate a different underlying issue althogether - we'll see.)
  

Whilst working on the above I also experienced problems with ntfsclone and the still very present NFS issue with kernel 2.6.17.
.

Because of bespoke NFS issue I tested with DVDs as backup media on amd64 with kernel 2.6.17-2-amd64 (2.6.17-7).

...is not only an interesting Ringo Starr album, but also describes quite fittingly the nature of an email I received today from Nathanael Nerode.
.

In his email, Nathanael inquires about #16827, which I had filed a whopping eight years and 231 days ago today.

I hadn't used neither olvwm nor LyX for many years (although especially the latter served me extremely well at the time). But I thought that Nathanael boldly going where noone had gone for more than eight years deserved an equally bold answer, so I installed and tested. The good news is that the issue does indeed appear to be fixed! :-)

There was this long-standing problem with Mondo Rescue that during restore runs the virtual consoles wouldn't work on amd64. I managed to finally track this down to a rather bizarre bug in glibc.
.

The problem is actually fixed in glibc 2.4. When I found out that 2.4 is not going to make it into etch, I asked whether the fix could be backported to 2.3. To my total delight, this is exactly what Aurelien did! Thank you a lot, indeed! :-)

Without further ado I thus bring you mindi-busybox-1.2.1 with working virtual consoles. (The only other noteworthy change is that there is a link now from /etc/mtab to /proc/mounts in the restore system to keep the new upstream busybox happy.)

Testing was done on:

• sid, i386, stock Debian kernel 2.6.17-2-k7 (2.6.17-6) to NFS
• sid, amd64, stock Debian kernel 2.6.16-2-k8-smp (2.6.16-17), LVM & RAID to NFS
  

...is to close the bug report and to see what happens. Or so it seems:

I decided to finally close #291975 last week after having been unable to reproduce the problem for some months. I've done this once before about a year ago but the issue resurfaced straight after. :-( (I have filed #290722 and later #351367 in regards to this.)

Anyway. A few days after having closed the bug report for the second time, version 0.52.2-5.1of libnewt0.52 is released and brings the problem back again - I've filed a new bug for this: #379938. (Maybe I should have just updated #351367 instead, but then again the issue is so very clearly tied to version 0.52.2-5.1 of libnewt0.52 - and also, I'm sure Alastair will merge as required.)

In light of this, becoming superstitious looks like a viable option...

Greg must have given an amazingly insightful, inspiring, and amusing keynote at OLS:
:

http://www.kroah.com/log/linux/ols_2006_keynote.html

I truly enjoyed reading this, maybe you will, too...

mondo-2.08-2-3 and mindi-1.08-2-1 are now in incoming and hopefully soon at a Debian mirror near you.

Apart from (finally) fixing the compiler warnings on amd64 by changing some int variables to long and a fix for image sizes getting wrongfully changed in mondorestore's partition editor, this is mainly about reducing screen corruption during restore - for people using RAID and/or LVM, the newt screens should not get partially or totally overwritten by some crap anymore.

I spent quite some time on the screen corruption fixes, partially because I have little knowledge of newt, partially because restore runs are always a pain to trouble-shoot and partially (especially in retrospect) because I can be a bit thick at times. ;-) However, I feel that fixing these types of "cosmetic" issues is well worth the effort, because it improves user experience and increases faith in the software - pretty important, particularly the latter, especially for disaster recovery software like Mondo Rescue. (It obviously still has to live up to it! ;-))

The new versions were tested on sid amd64 and i386 with native kernels and using NFS as backup media. Oh, and mindi should now also build out of the box on Ubuntu Dapper Drake.